Many communication networks support some sort of connection continuity monitoring function. Operations Administration and Maintenance continuity checking (OAM-CC) is an example of one such function for Asynchronous Transfer Mode (ATM) network connections. A version of OAM-CC also exists for Multi-Protocol Label Switching (MPLS) connections.
According to OAM-CC, cells are sent from a network element at one or both ends of a communication network connection, and a connection failure or fault, generally referred to as loss of continuity or LOC, is detected when the cells are not received when expected at the other end of the connection. Cell transmission and reception are typically accomplished by configuring an OAM-CC source at a network element at one end of a connection and an OAM-CC sink at a network element at the other end of the connection. OAM-CC sources inject OAM-CC cells into a dataflow on a connection, and OAM-CC sinks extract these cells from the dataflow for analysis. Bidirectional continuity checking is provided by configuring an OAM-CC source and sink at each end of a connection.
When a failure which causes a loss of continuity (LOC) in a connection occurs, due to a switch fabric failure or line card component failure for instance, the connection should be re-established as soon as possible to keep user services over the connection as continuous as possible. The action of detecting and re-establishing a connection as soon as possible after LOC is referred to herein as connection reroute on LOC.
One problem with conventional reroute on LOC is that the specific location along the path of the connection where a failure occurs is unknown. All that is known is that a failure, somewhere along the path, has occurred. According to one currently known reroute on LOC technique, a failed connection is rerouted based on a best path computed using the Private Network-to-Network Interface (PNNI) protocol, illustratively PNNI Specification Version 1.1, af-pnni-0055.002, April 2002. The best path, however, typically does not change and the rerouted connection thus often attempts the same path, traversing the same network nodes and links which experienced the failure in the first place. Although some LOC failures can be recovered when re-establishing connections over the same nodes and links in the network, it is generally best to avoid the failed portion of the network entirely so as to avoid repeated occurrences of the same failure. Avoiding the failed network elements increases the likelihood that connection reroute on LOC is able to re-establish user services when LOC is discovered.
The only known mechanism intended to address this problem is to keep track of the original path on a source node, and then find a completely diverse path when a failure occurs, thereby avoiding all original network elements, and accordingly any potentially failed elements, during the reroute. However, even with this solution, the location of the failure remains unknown. In addition, it may not be possible to set up an alternate diverse path which avoids all network elements in an original path. Further, the alternate diverse path is inherently inefficient and non-optimal since avoiding many network elements is costly and may very likely not be the optimal path after failure.
Therefore, there remains a need for improved failure detection and protection techniques which can locate the source of a connection failure and only reroute the connection around the actual failure location.